Rule-based bidding platform

ABSTRACT

A computing system is configured to accept bid rules from merchants for the placement of ads for a plurality of products. The bid rules comprise a bid amount, a rule definition and a priority. The bid amount may be an absolute bid or it may be relative to base advertising rate. The rule definition comprises criteria for describing products to determine when the bid rule is applied to a product for sale. The priority indicates whether the bid rule applies to a particular product when the rule definition of more than one bid rule could be applied to a product. The computing system is also configured to generate a list of product offers based at least in part on the bids. The system may also generate reports for merchants.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S.application Ser. No. 13/013,591, filed Jan. 25, 2011, which claimspriority to U.S. Provisional Application No. 61/298,176, filed Jan. 25,2010, each of which is hereby incorporated by reference in its entirety.

Additionally, this application relates to U.S. Pat. No. 8,321,279,issued Nov. 27, 2012, which is hereby incorporated by reference in itsentirety.

BACKGROUND

1. Field of the Disclosure

This disclosure relates to systems and methods for adjusting baseadvertising rates.

2. Background of the Disclosure

Currently, many merchants advertising products for sale on-line arecharged for advertising based on a cost-per-click (“CPC”) model. In theCPC model, a merchant is charged a fee each time a potential consumerclicks on an advertisement for the merchant's product offer. The CPCrates for goods or services are generally defined by a rate card. A ratecard defines advertising rates based on the type of good or servicebeing sold. Rate cards are traditionally set and updated by a merchant'saccount manager or by a media outlet offering advertising. When ratecards are set by the media outlet, a problem arises when many merchantsoffer the same product or service as it may become difficult formerchants to receive advantageous ad placement. Furthermore, the staticnature of rate cards prevents merchants from adjusting their advertisingbased on dynamic sales data. Thus, there is a need for allowingmerchants more flexibility in setting CPC rates.

SUMMARY OF THE DISCLOSURE

In one embodiment, a system accepts bid rules for making dynamicadjustments to the CPC rates of products offered for sale by a merchant.The system generates a computer interface for inputting bid rules. Eachbid rule may include a bid amount, a rule definition, and/or a priority.The bid amount indicates what adjustment is to be made to the CPC rateof a product offer. The bid amount may be absolute where it overridesthe CPC rate defined in the rate card for the product. In that case, themerchant is charged the bid amount as an advertising rate.Alternatively, the bid amount may be relative to the amount defined inthe rate card for the product. When the bid amount is relative, themerchant is charged the CPC rate defined in the rate card for theproduct plus the bid amount. Relative bid amounts may be negative. Therule definition (also referred to as a “bid criteria”) includes criteriafor matching products to the bid rule. A rule definition comprises oneor more product conditions. Each product condition may be one of price,taxonomy, manufacturer, and/or any other product attribute. In the casewhere bid criteria of multiple bids each match a particular productoffer, the system determines which bid rule applies to the product offerusing the priorities associated with the multiple matching bid rules.The system transmits the user interface to a merchant computing systemand then accesses the bid rule entered by the merchant. The presentdisclosure also describes systems and methods of accepting bid rules. Inone embodiment, a bidding platform computing device generates a computerinterface that may be used by merchants to provide bid rules for theadvantageous placement of ads offering products for sale. The bid rulesmay comprise a bid amount, a rule definition and a priority. The userinterface is transmitted to a merchant computing device and the biddingplatform computing device receives the bid rules entered by themerchant.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram illustrating one embodiment of a rule basedbidding platform computing system in communication with a consumercomputing system, a syndicate partner computing system and one or moremerchant computing systems.

FIG. 1B is a block diagram illustrating another embodiment of a rulebased bidding platform computing system in communication with a consumercomputing system, a syndicate partner computing system and one or moremerchant computing systems, where an exemplary temporal flow of data isoutlined.

FIG. 1C is a flowchart illustrating the temporal flow of data forsetting the CPC rate in one embodiment of a rule based bidding platformsystem in communication with a consumer, a syndicate partner computingsystem and one or more merchants.

FIG. 1D is a flowchart illustrating the temporal flow of data fordetermining the applicable bid rule for setting the CPC rate in oneembodiment of a bidding platform computing system in communication witha consumer, a syndicate partner and one or more merchants.

FIG. 2 is a block diagram illustrating one embodiment of a biddingplatform computing system.

FIG. 3 illustrates an exemplary user interface for viewing, editing andadding bid rules for merchant products.

FIG. 3A illustrates an exemplary user interface for adding bid rules formerchant products based on the price of the products.

FIG. 3B illustrates an exemplary user interface for adding bid rules formerchant products based on the taxonomy of the products.

FIG. 3C illustrates an exemplary user interface for adding bid rules formerchant products based on the manufacturer of the products.

FIG. 3D illustrates an exemplary user interface for adding bid rules formerchant products based on the taxonomy and the manufacturer of theproducts.

FIG. 3E illustrates an exemplary user interface for adding bid rules formerchant products based on the price, the taxonomy and the manufacturerof the products.

FIG. 3F illustrates an exemplary user interface for entering a bidamount. The bid amount can either be absolute, relative to the CPC ratecard value, or equal to the CPC rate card value.

FIG. 4A illustrates an exemplary user interface for setting the sourceof bids for merchant product offers.

FIG. 4B is a flowchart illustrating one embodiment of a method fordetermining the rule for setting the CPC value for a product offer basedon the selected source of bids.

DETAILED DESCRIPTION

Embodiments of the invention will now be described with reference to theaccompanying figures, wherein like numerals refer to like elementsthroughout. The terminology used in the description presented herein isnot intended to be interpreted in any limited or restrictive manner,simply because it is being utilized in conjunction with a detaileddescription of certain specific embodiments of the invention.Furthermore, embodiments of the invention may include several novelfeatures, no single one of which is solely responsible for its desirableattributes or which is essential to practicing the inventions hereindescribed.

FIG. 1A is a block diagram illustrating one embodiment of biddingplatform computing system 130 (or “bidding system 130”) in communicationwith consumer computing system 110, syndicate partner computing system120 (or “partner system 120”), and one or more merchant computingsystems 140 (including merchant computer system 140A, merchant computingsystem 140B, and merchant computing system 140N). Partner system 120may, for example, host a website where visitors may search for productsand/or product information. In addition, partner system 120 may presentproduct offers from multiple merchants offering products for sale.Consumer computing system 130 may access partner system 120 to searchfor products or product information in an attempt to find the mostattractive purchasing option. Partner system 120 may aggregate multipleproduct offers and generate a user interface displaying the productoffers and transmit it to consumer computing system 110. In oneembodiment, partner system 120 may present multiple product offers frommultiple merchants for the same product. Merchant computing systems 140may, for example, offer several products for sale. For example, consumercomputing system 110 may access a website hosted by one of merchantcomputing systems 140 to purchase a product. A user of consumercomputing system 110 may be able to purchase a product directly from oneof merchant computing systems 140.

In one embodiment, the system outlined in FIG. 1A is computerized,wherein each of the illustrated components comprises a computing devicethat is configured to communicate with other computer devices vianetwork 190. For example, consumer computing system 110 may comprise acomputing device, such as a desktop, notebook, or handheld computingdevice that is configured to transmit and receive data to/from othercomputing devices via network 190. Similarly, each of the merchantcomputing systems 140, syndicate partner computing system 120 andbidding platform computing system 130, may include one or more computingdevices that are configured to communicate data with other computingdevices via network 190. Depending on the embodiment, network 190 maycomprise one or more of any type of network, such as one or more localarea networks, wide area networks, personal area networks, telephonenetwork, and/or the Internet, which may be accessed via any availablewired and/or wireless communication protocols. Thus, network 190 maycomprise a secure LAN through which bidding platform computing system130 and partner system 120 communicate, and network 190 may furthercomprise an Internet connection through which bidding platform computingsystem 130 and consumer computing system 110 communicate. Any othercombination of networks, including secured and unsecured networkcommunication links, are contemplated for use in the systems describedherein.

FIG. 1B is a block diagram illustrating another embodiment of biddingplatform computing system 130, consumer computing system 110 and one ormore merchant computing systems 140 of FIG. 1A, where an exemplarytemporal flow of data is outlined. In particular, the circled numeralsof FIG. 1B illustrate the order in which data flows between the variouscomponents of FIG. 1B according to one embodiment. In anotherembodiment, the steps outlined by the circled numerals may be performedin a different order, and the method may include fewer or additionalsteps.

In step one of FIG. 1B, bidding platform computing system 130 receivesbid rules and product offers from one or more merchant computing systems140. In one embodiment, the bid rules are received through bidding tooluser interface 300 (FIG. 3) or similar user interface generated bybidding platform computing system 130. Bidding tool user interface 300may then be transmitted through network 190 to merchant computingsystems 140. A user of merchant computing systems 140 may enter one ormore bid rules through bidding tool user interface 300. In oneembodiment, a bid rule may modify the base CPC rate of a particularproduct offer when the rule definition of the bid rule matches theproduct of the product offer.

Rule definitions (also referred to as “bid criteria”) may comprisecriteria for identifying one or more products the merchant is offeringfor sale. In one embodiment, the rule definition criteria may includeone or more product conditions related to product prices. A productcondition related to price, for example, may indicate that a bid ruleapplies to products below a specific price, above a specific price orbetween two prices. In another embodiment, the rule definition criteriamay include one or more product conditions related to the producttaxonomies. For example, bidding platform computing system 130 maydefine categories that describe groups of products with different levelsof granularity, where each level provides a more specific description ofthe group of products. The highest level, for example, may beappliances, and the second highest level may be large kitchenappliances. The number of levels of granularity may vary from embodimentto embodiment as needed to accurately represent the products for whichbidding platform computing system 130 accepts bid rules. In oneembodiment, product taxonomy information provided by merchants isanalyzed in order to associate respective products into one or more ofthe categories established by bidding platform computing system 130.

In another embodiment, the rule definition may include one or moreproduct conditions related to the manufacturer of the product. Forexample, a product condition may indicate that a bid rule applies toproducts made by Brand X. In another embodiment, the rule definitioncriteria may include one or more product conditions related to any oneof price, taxonomy or manufacturer. A rule definition, for example, mayindicate that a bid rule applies to products that are laptop computers,priced below $1000, and manufactured by Brand X.

In some embodiments, rule definition criteria may include otherdescriptive information that may be used to identify a product or a setof products the merchant is offering for sale. For example, a ruledefinition may include other attributes independent of price, taxonomyor manufacturer, such as conversion rate (e.g., how many products soldper time period), product condition (new, used, excellent, good, fair,etc.), gender (e.g., for clothing), product compatibility (e.g., forauto parts, appliance parts, computers, etc.), size (e.g., for TVs, harddrives, etc.) or any other product-related attributes. Such attributesmay be extracted from the product offers received from merchantcomputing systems 140. In one embodiment, the extracted attributes ofproduct offers may not directly correspond to attributes that are usedby bidding system 130. In such cases, bidding system 130 may normalizemultiple sets of different product attributes received from multiplemerchants by mapping them all to a common set of attributes defined bybidding system 130. These common attributes may then be used toassociate respective products to one or more categories defined by themerchant 130. In this way, relationships between products of differentmerchants may be better compared using the same framework of attributesand categories. In another embodiment, bidding system 130 may mapmerchant defined product attributes to product categories (eithermerchant or bidding system defined product categories).

In one embodiment, bid rules are assigned priorities that are usable bybidding system 130 to select a highest priority bid rule in the casewhere bid criteria of multiple bid rules each match a particular productoffer. For example, this may occur when the rule definitions of the bidrules are defined in such generic terms that they overlap with respectto a particular product offered for sale by the merchant. In such cases,the priority of the bid rules may be used to determine which bid rule toapply to the product offer. For example, a merchant may enter a firstbid rule to modify the base CPC rate of all appliances and assign thebid rule a priority of 2. The merchant may enter a second bid rule thatmodifies the base CPC rate of all items manufactured by Brand X andassign the bid rule a priority of 1. If the merchant offers for sale anappliance made by Brand X, the rule definitions of the first bid ruleand second bid rule will apply to the product offer since the first bidrule is triggered when the product is an appliance and the second bidrule is triggered when the product is made by Brand X. The priority ofthe first bid rule and second bid rule will then be used to determinewhich bid rule to apply to the product offer. In this example, thesecond bid rule that modifies the CPC rate based upon the manufacturerwould apply to the product offer since it has a higher priority.Accordingly, the base CPC rate will be adjusted based upon the bidamount of the second bid rule.

In one embodiment, bid rules are assigned bid amounts that are used todetermine how the base CPC rate defined in the rate card may be modifiedwhen the rule definition of the bid rule applies to a product offer. Inone embodiment, the bid amount may be absolute such that the bid amountis used in place of a base CPC rate defined in the rate card. In anotherembodiment, the bid amount may be relative such that the bid amount isused to modify the base CPC rate defined in the rate card by the bidamount.

In another embodiment, bid rules may be set for specific products, suchthat the bid amounts of the product-specific bid rules override the baseCPC rate of a product offer for the specific product. The biddingplatform computing system 130 may generate a user interface forinputting product-specific bid rules and transmit the user interface tomerchant computing systems 140. The user interface may provide searchfunctionality allowing any one of merchant computing systems 140 theability to find a particular product. The search functionality, forexample, may include searching by price, taxonomy or manufacturer. Inanother embodiment, the search functionality may include searching basedon any one of, or any combination of, price, taxonomy, manufacturer,and/or any other product attribute. The user interface may allow entryof bid amount. In one embodiment the bid amount be absolute, and inanother embodiment it may be relative.

Referring back to step 1 of FIG. 1B, in another embodiment, biddingplatform computing system 130 may receive CPC rates (e.g., bids) from adata feed as opposed to bidding tool user interface 300. In oneembodiment, the data feed may include bid for specific products asopposed to a group of products, such that the bid amounts of theproduct-specific bid override the CPC rate of a product offer for thespecific product. In another embodiment, the data feed may support entryof bid that modify the base CPC rate of a product offer based upon oneor more rule definitions as described above. The data feed may comprisea text file, an spreadsheet, an XML file, a serialized object, a bytestream or any other mechanism known in the art to communicate databetween computing systems.

Referring again to step 1 of FIG. 1B, in one embodiment, merchantcomputing systems 140 may provide bidding platform computing system 130a list of product offers. Bidding platform computing system 130 mayreceive the list of product offers from the merchant computing systemvia the data feed described above. Each product offer may include, forexample, a product description, a price, a model number and one or moredescriptors related to the taxonomy of the product. The taxonomy of theproduct may relate to the category of good of the product offered forsale.

In one embodiment, bidding system 130 calculates the adjusted CPC rateof product offers whenever merchant computing systems 140 send anupdated product offer list. Thus, the CPC rate for each of the productsin a merchant's product offer list is determined and stored by thebidding system 130 so that the CPC rates are available in response torequests for placement of the various products to consumers. In someembodiments, bidding system 130 may calculate the adjusted CPC rate ofproduct offers periodically or based on a predetermined schedule.Alternatively, bidding system 130 may calculate the adjusted CPC rate ofproduct offers when merchant computing systems 140 submit new bid rules.In another embodiment, bidding system 130 may calculate the adjusted CPCrate of product offers based on any combination of the above methods.

In step 2 of FIG. 1B, consumer computing system 110 may make a requestfor product offers for one or more products, such as via a productsearch interface wherein the consumer typed a product search query. Inone embodiment, the request may be for a uniquely identified product,such as a request for a particular make/model of product. In anotherembodiment, the request may be for a generically identified product,such as a general type of product. In one embodiment, the request,includes a set of criteria specified by the user of consumer computingsystem 110, such as one or more product category, search keyword(s),and/or any other product attribute filter. In one embodiment, therequest may be received by a syndicate partner computing system 120. Thesyndicate partner computing system 120 may provide a user interface forentry of requests from a consumer computing system 110.

In step 3 of FIG. 1B, bidding platform computing system 130 receives arequest for product offers from partner computing system 120. In oneembodiment, the request that bidding system 130 receives from syndicatesystem 120 is the same request that syndicate system 120 received fromconsumer computing system 110. In another embodiment, syndicate system120 modifies the request received from the consumer computing system110. In another embodiment, bidding platform computing system 130 mayreceive a request for a product offer directly from consumer computingsystem 110. For example, partner system 120 may not be involved in theprovision of product offers to the consumer computing system 110 in thisembodiment. Instead, bidding system 130 may provide a user interface forentry of a request directly to the consumer computing system 110.Depending on the embodiment, the request may be for a uniquelyidentified product, for a generically identified product, and/or forproducts that match keywords provided by the consumer computing system110. For example, product requests, whether from the consumer computingsystem 110 or the partner system 120, may not be for specific products,but rather, for a group of products based on product category, a searchkeyword or any product attribute filter describing one or more products.

In step 4 of FIG. 1B, bidding system 130 generates a list of productoffers for the products matching the request received from partnercomputing system 120 (or in another embodiment, received directly fromconsumer computing system 110). In one embodiment, bidding system 130determines the product offers matching the request. If more than oneproduct offer matches the request, bidding system 130 may order theproduct offers based at least in part on the calculated CPC rate ofproducts when it generates the list of matching product offers. Inanother embodiment, bidding system 130 may determine that some productoffers matching the request will be excluded from the generated list ofmatching product offers. For example, product offers may be excludedbased at least in part on the calculated CPC rate of the product offerand conditions established by syndicate partner computing system 120. Inanother embodiment, product offers may be excluded based on the identityof the merchant making the product offer. In one embodiment, once thelist of matching product offers is created, bidding system 130 sends thelist to partner computing system 120. In another embodiment, the list issent to consumer computing system 110. In another embodiment, biddingsystem 130 generates a list of products, as opposed to product offers,matching a general request, such as one or more product category, searchkeyword(s), and/or any other product attribute filter, for products frompartner computing system 120, or in other embodiments, consumercomputing system 110. Bidding system 130 may determine a particularproduct offer to feature in the product list based at least in part onthe calculated CPC rate for the particular product offer. For example,bidding system 130 may use special fonts, graphics or other displays tohighlight a particular product offer having a highest CPC. In oneembodiment, bidding system 130 uses the determined featured productoffer as a representative product offer for a product category in a listincluding one or more product categories each associated with productsmatching a general product request. For example, if bidding system 130received a request for washing machines from partner system 120, biddingsystem 130 may determine that product categories A, B and C match therequest. Bidding system 130 may also determine that product offer Xshould be featured for category A, product offer Y should be featuredfor category B, and product offer Z should be featured for category C.When generating the list of products, bidding system 130 may use productoffers X, Y and Z as representative offers of product categories A, Band C, respectfully.

Moving to step 5 of FIG. 1B, consumer computing system 110 receives thelist of product offers. In one embodiment, the list is received frompartner computing system 120. In another embodiment, the list isreceived from bidding system 130. In one embodiment, the product offerlist may include one or more hyperlinks to a user interface generated bymerchant computing systems 140 offering the product for sale. In anotherembodiment, consumer computing system 110 receives the list of products,but not product offers. The product list may include one or morehyperlinks to a user interface generated by bidding system 130 listingthe product offers corresponding to the product. The user interface mayorder the product offers based at least in part on the calculated CPCrate of each product offer.

In step 6 of FIG. 1B, bidding system 130 receives data representing aproduct offer selected by the consumer using the consumer computingsystem 110. In one embodiment, the received data indicates whichmerchant computing system 140 offered the product for sale. This datamay be used, for example, to determine the amount to charge the operatorof the merchant computing system for the selection of its product offerby consumer computing system 110. In one embodiment, this determinationis based in part on the calculated CPC rate of the selected productoffer. In another embodiment, bidding system may use the received datawhen generating reports for merchants.

FIG. 1C is a flowchart illustrating one embodiment of a method forsetting the CPC rates of a plurality of products. In one embodiment, themethod of FIG. 1C is performed by bidding system 130. However, themethod may be performed by any other suitable computing device.Depending on the embodiment, the method may include fewer or additionalblocks and/or the blocks may be performed in a different order than isillustrated.

Beginning in block 145, bidding system 130 receives bid rules frommerchant computing systems 140. As described above, the bid rules may bereceived via a bidding tool user interface 300 or, in anotherembodiment, a data feed.

Next, in block 150, for each product the merchant offers for sale,bidding system 130 determines the applicable bid rule for setting theCPC rate of the product. For example, the bidding system 130 applies thebid rules established by the merchant in order to determine theappropriate CPC for each product. This process is described in furtherdetail with reference to FIG. 1D, below.

Finally, in block 160, once the applicable bid rule is determined forrespective products, bidding system 130 sets the CPC for the productsbased upon the respective applicable bid rule. In one embodiment, theCPC calculation may include the cost of additional services to increaseproduct offer visibility in addition to the bid amount. For example, theCPC calculation may include the cost of displaying a logo, customcolors, custom fonts, displaying special images, banner placement,designation as a featured product, designation as a featured merchant,or any other means of increasing product offer visibility.

In one embodiment, the CPC rate may be calculated using a bid rule wherethe bid amount is absolute and overrides the base CPC rate defined inthe rate card for the product. In another embodiment, the CPC rate maybe calculated using a bid rule where the bid amount is relative to thebase CPC rate defined in the rate card for the product. When the bidamount is relative to the base CPC rate for the product, the base CPCrate is adjusted by the bid amount and the final CPC rate is calculatedusing the adjusted base rate and the rate for any additional services toincrease product visibility. Relative bid amounts may be a price value,such as $0.10, or in other embodiments, may be a percentage, such as10%. Percentages may be positive, indicating a percentage increase inthe rate card rate, or negative, indicating a percentage decrease in therate card rate

FIG. 1D is a flowchart illustrating one embodiment of a method ofdetermining of the applicable bid rule for each of a plurality ofproducts offered by a merchant. The method 150 of FIG. 1D may be part ofthe method of FIG. 1C. In one embodiment, the blocks of FIG. 1D may beperformed when a merchant submits a data feed describing the productsthe merchant wishes to offer for sale. In another embodiment, the blocksof FIG. 1D may be performed on a periodic basis by bidding system 130,e.g., using a product list and/or bid rules that may have been updatedby the merchant since the CPC rates were last set. In anotherembodiment, the blocks of FIG. 1D may be performed by bidding system 130in response to receiving a new bid criteria from merchant computingsystem 140. Depending on the embodiment, the method of FIG. 1D mayinclude fewer or additional blocks and blocks may be performed in adifferent order than is illustrated.

As described herein, the method of FIG. 1D is performed for each productoffered for sale by a merchant, such that one bid rule is selected foreach product and that bid rule can be used to set the CPC for therespective product offer. Beginning in block 152, the bidding system 130selects a product from the plurality of products offered by a particularmerchant, and accesses information regarding the product. For example,the bidding system 130 may select products in a sequential order, or inany other order.

Once a specific product is selected, in block 156 the bidding system 130selects the next bid rule defined by the merchant for comparison withthe currently selected product. Bidding system 130 may cycle through thebid rules in any order.

In block 156, bidding system 130 analyzes the rule definition of the bidrule in order to determine if the product satisfies the rule definition.As stated above, a rule definition may have one or more productconditions associated with various product attributes. Bidding system130 compares the product conditions of the selected bid rule to theselected product. If the product satisfies all of the productconditions, the method continues to block 158 where the bid rule isadded to a set of matching bid rules. If the product does not match therule definition at block 156, the method continues to block 160 withoutadding the select bid rule to the list of matching bid rules.

In block 160, the bidding system 130 determines if there are more bidrules defined by the merchant offering the product for sale. If so, themethod returns to block 154 and the bidding system 130 repeats blocks154-160 for another bid rule defined by the merchant.

When the bidding system 130 determines in block 160 that there are nofurther bid rules to compare to the selected product, the methodcontinues to decision block 162 where the bidding system 130 determinesif there are one or more bid rules matching the product (e.g., if thereare any bid rules on the list of matching bid rules). If there are nomatching bid rules, bidding system 130 sets the CPC to the rate cardvalue for the product in block 164 (or to some other value that ispredetermined by the bidding system 130 and or the merchant in otherembodiments).

In block 166, the bidding system 130 determines the applicable bid rulefor the selected product based on the priorities of the matching bidrules. If there is only one matching bid rule, then the bid amount fromthat bid rule will be used to set the CPC, without consideration of thepriority for the one matching bid rule. However, if there is more thanone matching bid rule, then bidding system 130 determines the applicablebid rule based on the respective priority of each bid rule. In oneembodiment, the bid rule with the highest priority will be set to theapplicable bid rule. In one embodiment, the priority is a numericalvalue. The numerical value may represent a ranking order for the bidrules. For example, a bid rule with a priority of 1 would have a higherpriority than a bid rule with a priority of 2. In another embodiment,the priority may be represented with letters or other symbols indicatingan ordinal value. As noted in block 160 of FIG. 1C, once the applicablebid rule is determined, the base CPC rate for the product is set usingthe bid amount of the applicable bid rule. As stated above, bid amountsmay be absolute or relative to the rate card rate. If the bid amount isabsolute, the CPC rate is set to the bid amount. If the bid amount isrelative, the rate card rate for the product is adjusted by the bidamount to determine the base CPC rate.

In another embodiment, the order of the calculation of modified base CPCrates may be based on the priority of the bid rules defined by merchantcomputing systems 140. For example, in one embodiment, bidding system130 may select all of the bid rules for a merchant and start modifyingCPC rates based on the bid rule with the highest priority. This may be,for example, the bid rule where the priority is set to 1. Next, biddingsystem 130 may determine all product offers that match the ruledefinition for the bid rule and modify the base CPC rates for thoseproduct offers. Then, bidding system 130 may analyze the bid rule withthe second highest priority, for example, the bid rule where thepriority is set to 2. Bidding system 130 then determines all productoffers that match the rule definition for the bid rule of the secondhighest priority and for which bidding system 130 did not already modifythe base CPC rate. Bidding system 130 then modifies the base CPC ratesof the determined products. Bidding system then repeats the process foreach bid rule of decreasing priority until all bid rules have beenanalyzed. In this embodiment, each time a bid rule is matched to one ormore products, the lower priority bid rules are applied to a smaller setof products (because products that already have a higher prioritymatching bid rule are not again analyzed with reference to lowerpriority bid rules). Thus, the lower priority bid rules may be appliedto a smaller (possibly much smaller) portion of the products, allowingthe bid system 130 to more quickly assign advertising rates for productoffers.

FIG. 2 is a block diagram illustrating one embodiment of bidding system130. In one embodiment, bidding system 130 is configured to interfacewith multiple devices and/or data sources, such as in the exemplarynetwork configurations of FIGS. 1A and 1B. Bidding system 130 may beused to implement certain systems and methods described herein. Forexample, in one embodiment bidding system 130 may be configured togenerate bidding tool user interface 300, access bid rules from merchantcomputing systems 140, determine CPC rates for merchant products basedon merchant-defined bid criteria, access requests from consumercomputing system 110 and partner computing system 120 in order toidentify product offers to be provided to consumer computing system 110,generate a list of matching product offers to provide to the consumercomputing system 110 (which doesn't necessarily include all of thematching product offers), and generate a user interface for displayingthe list of matching product offers. The functionality provided for inthe components and modules of bidding system 130 may be combined intofewer components and modules or further separated into additionalcomponents and modules.

In general, the word module, as used herein, refers to logic embodied inhardware or firmware, or to a collection of software instructions,possibly having entry and exit points, written in a programminglanguage, such as, for example, C, C++, or C#. A software module may becompiled and linked into an executable program, installed in a dynamiclink library, or may be written in an interpreted programming languagesuch as, for example, BASIC, Perl, or Python. It will be appreciatedthat software modules may be callable from other modules or fromthemselves, and/or may be invoked in response to detected events orinterrupts. Software modules may be stored in any type ofcomputer-readable medium, such as a memory device (e.g., random access,flash memory, and the like), an optical medium (e.g., a CD, DVD, BluRay,and the like), firmware (e.g., an EPROM), or any other storage medium.The software modules may be configured for execution by one or more CPUsin order to cause the computing system 140 to perform particularoperations.

It will be further appreciated that hardware modules may be comprised ofconnected logic units, such as gates and flip-flops, and/or may becomprised of programmable units, such as programmable gate arrays orprocessors. The modules described herein are preferably implemented assoftware modules, but may be represented in hardware or firmware.Generally, the modules described herein refer to logical modules thatmay be combined with other modules or divided into sub-modules despitetheir physical organization or storage.

In one embodiment, bidding system 130 includes, for example, a server ora personal computer that is IBM, Macintosh, or Linux/Unix compatible. Inanother embodiment, bidding system 130 comprises a laptop computer,smart phone, personal digital assistant, or other computing device, forexample. In one embodiment, the exemplary bidding system 130 includesone or more central processing units (“CPU”) 220, which may include oneor more conventional or proprietary microprocessors. Bidding system 130further includes a memory 240, such as random access memory (“RAM”) fortemporary storage of information and a read only memory (“ROM”) forpermanent storage of information, and a data store 200, such as a harddrive, diskette, or optical media storage device. In certainembodiments, the data store 200 stores product data, bid data and/ormerchant data. Embodiments of data store 200 may store data indatabases, flat files, spreadsheets, or any other data structure knownin the art. Typically, the modules of bidding system 130 are incommunication with one another via a standards based bus system. Indifferent embodiments, the standards based bus system could bePeripheral Component Interconnect (PCI), Microchannel, SCSI, IndustrialStandard Architecture (ISA) and Extended ISA (EISA) architectures, forexample. In another embodiment, bidding system 130 leverages computingand storage services available over the Internet (cloud computing).

Bidding system 130 is generally controlled and coordinated by operatingsystem and/or server software, such as the Windows 95, 98, NT, 2000, XP,Vista, Linux, SunOS, Solaris, PalmOS, Blackberry OS, or other compatibleoperating systems. In Macintosh systems, the operating system may be anyavailable operating system, such as MAC OS X. In another embodiment,bidding system 130 may be controlled by a proprietary operating system.Conventional operating systems control and schedule computer processesfor execution, perform memory management, provide file system,networking, and I/O services, and provide a user interface, such as agraphical user interface (“GUI”), among other things.

The exemplary bidding system 130 may include one or more commonlyavailable input/output (I/O) interfaces and devices 230, such as akeyboard, mouse, touchpad, and printer. In one embodiment, the I/Odevices and interfaces 230 include one or more display device, such as amonitor, that allows the visual presentation of data to a user. Moreparticularly, a display device provides for the presentation of GUIs,application software data, and multimedia presentations, for example. Inone embodiment, I/O interfaces and devices 230 comprise devices that arein communication with modules of bidding system 130 via a network, suchas network 190 and/or any secured local area network, for example. Inthe embodiment of FIG. 2, the I/O devices and interfaces 230 provide acommunication interface to various external devices. For example, inthis embodiment bidding system 130 is in communication with a network,such as any combination of one or more LANs, WANs, or the Internet, forexample, via a wired, wireless, or combination of wired and wireless,connections via a network interface of the I/O devices and interfaces230.

In the embodiment of FIG. 2, bidding system 130 also includes severalapplication modules that may be executed by CPU 220. More particularly,the application modules include custom bid rule module 250, productretrieval module 260, product bid module 270, import data feed module280, consumer interface module 290, and reporting module 210.

In one embodiment, custom bid module 250 may comprise software codeexecutable by CPU 220 that handles the generation of user interfaces forinputting bid information such as bidding tool user interface 300.Custom bid module 250 may also access bid rules inputted into thegenerated user interfaces by merchant computing systems 140. In oneembodiment, the generated user interfaces may be transmitted via network190 using I/O interfaces and devices 230. In one embodiment, custom bidmodule 250 may store and access merchant bid rules in/from data store200.

Product retrieval module 260, in one embodiment, may comprise softwarecode executable by CPU 220 that handles retrieval of product offers fromdata store 200. For example, the retrieval may be in response to arequest from consumer computing system 110 or partner computing system120. In one embodiment, product retrieval module 260 may be configuredto calculate CPC rates for product offers as described above withreference to FIGS. 1C and 1D.

Product bid module 270, in one embodiment, may comprise software codeexecutable by CPU 220 that handles the calculation and modification ofCPC rates for product offers. For example, in one embodiment, productbid module 270 may calculate CPC rates as described in FIG. 1C and FIG.1D. In another embodiment, product bid module 270 may calculate CPCrates for each merchant in bid priority order. For example, for eachmerchant, product bid module 270 may first determine the advertisingrates for the product offers matching the rule definition of the bidrule having a priority of 1. Then, product bid module 270 may determinethe advertising rates for the product offers matching the ruledefinition of the bid rule having a priority of 2 which were not alreadydetermined. Product bid module 270 may repeat this process until all bidrules for a merchant have been analyzed. In one embodiment, product bidmodule 270 may store and access modified CPC rates in/from data store200.

In one embodiment, import data feed module 280 is software codeexecutable by CPU 220 that handles the import of data feeds. Data feedsmay be received from merchant computing systems 140 and may include theproduct offers of the merchants as well as bid rules to modify the baseCPC rate for particular products. In another embodiment, import datafeed module 280 may also access bid rules from merchant data feeds thatinclude rule definitions as described above.

Consumer interface module 290 may include, in one embodiment, softwarecode executable by CPU 220 that generates user interfaces sent toconsumer computing systems 110. The generated user interfaces may beused by consumer computing devices to request product offers frombidding system 130.

In one embodiment, bidding system may include reporting module 210,which may comprise software code executable by CPU 220 that handlescreation of reports that can be accessed by merchant computing systems140. The reporting module may generate reports that list all of theproducts a merchant may offer for sale. The generated reports mayinclude historical product information and may include informationpertaining to the number of clicks a product has received over time.Reports may include information, for example, pertaining to productdescription, rate card rates, bid rules, CPC increases for holidays,costs for additional services for increasing visibility of the product,product identifiers such as UPC/ISBN, manufactures, prices, and numberof clicks.

In one embodiment, reports may be provided as user interface that allowsmanipulation of the data in the report by the user of the merchantcomputing device. For example, reports may allow merchants to specifydate ranges for display, where the date ranges may be inputted via acalendar pop-up interface. In another embodiment, reports may allow theuser to sort the information based on the number of clicks a product hasreceived. In addition, the reports may allow merchants to search forindividual products or groups of products by price, taxonomy ormanufacturer. Furthermore, the reports may allow merchants to show orhide data columns. In one embodiment, reporting module 210 may permitmerchant computing systems 140 to export data in a customized format.The customized format may include .CSV files, spreadsheets, text files,proprietary formats for databases or reporting engines, serializedobjects or some other data format known in the art. In one embodiment,the reporting module 210 may be configured to automatically generate andsend a custom report to the merchant computing device.

As noted above, a bid rule may comprise a bid amount that is relative tothe rate card rate. In one embodiment, the relative rate card rate maybe negative, that is, the bid rule will adjust the base CPC for theproduct to a value below the rate card rate for the product. In oneembodiment, the report generated by reporting module 210 may include avisual indicator such as a red “!” icon next to product offers with aCPC rate below the rate card to indicate the product offer may notappear in some lists generated in response to consumer product requests.

FIG. 3 illustrates an exemplary bidding tool user interface 300 forviewing, editing, and adding bid rules for merchant products. In oneembodiment, bidding tool user interface 300 is generated by custom bidrule module 250 of bidding system 130 and is accessed via a web browser(or other software) on the merchant computing device. In the embodimentof FIG. 3, bidding tool user interface 300 includes a bid rule table 310including several columns. This sample bid rule table 310 includescolumns listing the bid rule type (e.g. the product offer attributesrelevant to the bid, such as taxonomy, manufacturer, or price), the bidcriteria (e.g., the rule definition), the bid type (e.g., relative orabsolute), the bid amount, and the bid priority for each bid rule. Inother embodiments, additional or less information may be received foreach bid rule. Bidding tool user interface 300 may also include add newbid rule panel 320. Add new bid rule panel 320 may include biddefinition panel 330 as well as bid amount panel 340.

In the embodiment of FIG. 3, bid rule table 310 includes user interfaceelements allowing the user to alter the elements of bid rules. Forexample, edit icon 312 and delete icon 311 allow a user to edit ordelete a bid rule, respectfully, from bid rule table 310. In oneembodiment, when a user selects delete icon 311, the user interface maydisplay a confirmation (not shown) asking the user to confirm thatbidding system 130 should delete the bid rule. In addition, when a userselects edit icon 312, a user interface for editing the bid rule may bedisplayed. The user interface for editing a bid rule may be similar tothe user interfaces described in FIGS. 3A-3F with the bid ruleinformation pre-populated.

The user interface 300 also indicates bid priorities in column 316 andprovides interfaces for adjusting the priorities of bid rules. In thisparticular embodiment, the priority of bid rules may be adjusted up ordown using the up arrow 313 and down arrow 314 user interface elements.For example, when a user selects up arrow 313, the priority of theassociated bid rule will increase by one. Alternatively, when a userselects down arrow 314, the priority of the associated bid rule willdecrease by one. In one embodiment, the priority may also be adjusted inbid rule table 310 by directly inputting the bid priority in bid ruletable 310. When the priority of one bid rule is adjusted by the user,bidding system 130 will then adjust the priorities of other bid rules,as necessary. For example, when Bid rule A has priority 5 and Bid rule Bhas priority 4 and a user selects up arrow 313 associated with Bid ruleA, bidding system 130 will change Bid rule A's priority to 4 and Bidrule B's priority to 5. Alternatively, if a user enters a priority thatalready exists when adding or editing a bid rule, bidding system 130will assign the new bid rule the entered priority and will adjust allother affected bid rules accordingly. For example, if a user defines newBid rule X with priority of 5, and Bid rule Y already has priority 5,bidding platform will adjust Bid rule Y's priority to 6. In this manner,bidding system 130 will insure that each bid rule in the system has aunique priority for a given merchant so that if there are multiple bidrules applicable to a product, only one bid rule will be applied to theproduct in accordance with the process outlined in FIG. 1D.

FIGS. 3A-3E each illustrates the bid definition panel 330 of FIG. 3 withdifferent bid rule conditions selected. As noted above, the biddefinition panel 330 may be used to add or edit merchant bid rules basedon any combination of price, taxonomy or manufacturer. Bid definitionpanel 330 includes check box inputs 331, 334 and 336 for selecting whatproduct conditions (e.g., price, taxonomy, or manufacturer) will be usedto define a bid criteria. For example, in the user interface depicted inFIGS. 3A-3E, a user may select any one of price, taxonomy ormanufacturer. As illustrated in FIG. 3D, more than one product conditionmay be selected for a rule definition. While taxonomy and manufacturerare selected in the embodiment depicted in FIG. 3D, it can beappreciated that any combination of price, manufacturer or taxonomy maybe selected. Furthermore, other product conditions may be used in otherembodiments. In the embodiment of FIGS. 3A-3E, the bid definition panel330 also allows input of a priority for each bid rule in prioritydefinition text field 333. It can be appreciated that when a userdefines a priority using priority definition text field 333, biddingsystem may need to adjust the relative priority of already entered bidrules as described above.

FIG. 3A specifically illustrates an exemplary user interface for addingbid rules for merchant products based on the price of the products. Inone embodiment, a user may select checkbox 331 indicating that a pricecondition is part of the rule definition for the bid rule. In oneembodiment, a user may select one of a set of radio buttons 332indicating the logical condition associated with the price valueentered. For example, a user may define a price condition to be equalto, greater than, or less than a particular price. Alternatively, a usermay define a range for the price condition such that the rule definitionis satisfied if the price of a product is greater than a first value,but lower than a second value.

FIG. 3B specifically illustrates an exemplary user interface for addingbid rules for merchant products based on the taxonomy of the products.In one embodiment, a series of drop-down lists 335 are provided for auser to select an appropriate channel, category and/or sub-category fora particular product. Drop-down lists 335 may only be visible and activeif taxonomy check box 334 is selected. The channel drop-down list may bepre-populated with descriptions of predefined product-groups at the mostgeneric level. For example, the channel drop-down list may bepre-populated with descriptions such as appliances, sporting goods,computers, musical instruments and the like. Once a user selects achannel, bidding system 130 then populates the category drop-down listwith the available categories within that channel. For example, if auser selects appliances as the channel, the category drop-down maypopulate with descriptions such as air cleaners and heating appliances,home appliances, large kitchen appliances, laundry, small kitchenappliances, vacuum cleaners, and the like. After a user selects acategory, bidding system 130 will then populate the sub-categorydrop-down list with the available sub-categories within the category.For example, if a user selects appliances as the channel and laundry asthe category, the sub-category drop-down may populate with descriptionssuch as clothes dryers, clothes irons, laundry parts and accessories,washer/dryer combos, washing machines, and the like. By allowingpre-population of drop-down lists for product conditions based ontaxonomy, bidding system 130 insures that only valid rule definitionsmay be submitted by merchant computing systems 140.

FIG. 3C specifically illustrates an exemplary user interface for addingbid rules for merchant products based upon product manufacturers. In oneembodiment, check box 336 may be selected indicating that a ruledefinition comprising a manufacturer product condition is being added.Once check box 336 is selected, manufacturer text field 337 may bevisible so that a user may enter a manufacturer for triggering theproduct condition. In one embodiment, a list of available manufacturersmatching the text entered by the user is displayed so that the user mayselect a manufacturer from the available list. For example, in FIG. 3C,the user typed “Sony” and all manufacturers starting with “Sony” weredisplayed in an available list. The user may then select a manufacturerfrom the list of available manufacturers. By allowing selection from anavailable list of manufacturers, bidding system 130 insures that onlyvalid rule definitions may be submitted by merchant computing devices.

FIGS. 3D and 3E illustrate exemplary user interfaces for adding bidrules for merchant products based on multiple product conditions. InFIG. 3D, check boxes 334 and 336 are selected indicating that the ruledefinition for the bid rule will comprise a product conditions relatedto taxonomy and manufacturer. In FIG. 3E, check boxes 331, 334 and 336are selected indicating that the rule definition for the bid rule willcomprise a product conditions related to price, taxonomy andmanufacturer. While not shown in the figures, it may be appreciated thatthe rule definition of a bid rule may include any combination of price,taxonomy and/or manufacturer. In one embodiment, the entry of priceconditions, taxonomy conditions and manufacturer conditions arecompleted in the same manner as described regarding FIGS. 3A-3C.

FIG. 3F illustrates an exemplary user interface for entering a bidamount, specifically, bid amount panel 340 that may be part of add newbid rule panel 320. In one embodiment, bid amount panel 340 may includetext field 341 for entering a bid amount. Bid amount panel, in oneembodiment, may also provide a set of radio buttons 342 for selectingthe bid type. For example, a bid type may be absolute, relative to theCPC rate card rate, or equal to the rate card value. In one embodiment,when the absolute radio button is selected, a user may enter a value intext field 341 that will override the current CPC rate card rate for anyproducts matching the associated bid criteria (where the bid rule is thehighest priority matching bid rule). Alternatively, when the relative tothe CPC rate card rate radio button is selected, a user may enter avalue in text field 341 that is relative to the CPC rate card rate. Inone embodiment, a negative value may be entered for a relative bid. Insuch cases, the resulting bid will result in a base CPC rate that islower than the CPC rate card rate. In another embodiment, a percentagevalue may be entered for a relative bid. Percentages may be positive,indicating a percentage increase in the rate card rate, or negative,indicating a percentage decrease in the rate card rate. Alternatively,when the use rate card value radio button is selected, the resulting bidwill be at the rate card rate. In one embodiment, when the use rate cardvalue radio button is selected, text field 341 may be hidden from bidamount panel 340. In another embodiment, text field 341 may bedeactivated, grayed out, or may prevent user input in some other manner.

FIG. 4A illustrates an exemplary user interface for setting the sourceof bids for merchant product offers, specifically, bid source panel 400.Bid source panel 400 may include a set of radio buttons 410 indicatingthe source of bids. In one embodiment, set of radio buttons 410 mayinclude a radio button for setting the source to the input feed. Whenselected, bids will be determined based on values imported from the datafeed received by bidding system 130 from merchant computing systems 140as described above. Set of radio buttons 410 may also include a usebidding tool radio button. When selected, bidding system 130 may usebids as determined based on bid rules defined via a bidding tool, suchas bidding tool user interface 300, for example. The set of radiobuttons may also include an option to allow the user to set the sourceof bids to the rate card. When selected, bids entered from the importfeed or the bidding tool will be ignored by bidding system 130, and thebase CPC rate of product offers will be set to the value indicated inthe rate card.

FIG. 4B is a flowchart illustrating one embodiment of a method fordetermining the rule for setting the CPC value for a product offer basedon the selected source of bids. In one embodiment, if the source of bidsis set to use rate card values, then the base CPC for product offers isset to the rate card value for each of the respective products.Alternatively, if the source of bids is set to use the import data feed,the base CPC for product offers is set based upon information receivedfrom the data feed imported from merchant computing systems 140.Alternatively, if the source of bids is set to use custom bid rules,bidding system 130 calculates the CPC for each product based on the bidrules previously received from merchant computing systems 140. Forexample, bidding system 130 may access the bid rules defined by themerchant and identify the highest priority matching bid rule for eachproduct in order to determine the CPC rate for the products.

Other Embodiments

Another embodiment of bidding platform computer system 130 allows agroup voucher retailer (“GVR”) to dynamically adjust CPC rates for thevouchers it offers for sale. A GVR is a merchant that sells vouchers orcoupons that are redeemable for the goods or services of a differentmerchant or services provider. For example, a GVR might offer to sell acoupon for $10 providing for a 50% discount for a meal at a restaurant,or might offer to sell a coupon for $50 providing for a $100 discountfor an appliance. A GVR, similar to a merchant operating merchantcomputing system 140, may provide a website where consumers may purchasethe vouchers it offers for sale. To promote its voucher offers, a GVRmay wish to direct consumer traffic to its website and might do sothrough advertising based on a CPC model. Like CPC rates for productoffers, CPC rates for voucher offers may be defined by a rate card. AGVR may host a website where visitors may search for vouchers/couponsoffered for sale. Additionally, one or more partners may host websiteslisting offers from one or more GVRs. Consumer computing system 130 mayaccess the GVR or partner system to search for vouchers or coupons in anattempt to find the most attractive voucher/coupon. The GVR or partnersystem may, in turn, request from bidding system 130 a list of voucheroffers. The bidding system 130 may return a list to the GVR or partnerbased in part on the CPC rate of voucher offers matching the request.

In one embodiment, bidding system 130 facilitates advantageous adplacement by accessing bids from computing systems operated by GVRs.GVRs may submit bid rules that determine when a bid to modify the CPCrate of voucher offers should trigger. Entry and application of bidrules to voucher offers is similar to the entry and application of bidrules to product offers as described in other embodiments above. Forexample, a GVR may enter a bid rule into bidding tool user interface 130with a rule definition comprising criteria for identifying one or morevouchers the GVR is offering for sale. In another embodiment, biddingsystem 130 may receive bids from a data feed as opposed to a biddinguser interface (similar to bidding tool user interface 300). The ruledefinition criteria may comprise price, taxonomy, brand (similar tomanufacturer), and/or other criteria. For example, a rule definition mayinclude taxonomy criteria such that a bid rule is triggered when thevoucher or coupon may be redeemed at a services provider that belongs tochannel “restaurants” and category “Italian.” In another embodiment, therule definition criteria may include brand or manufacturer criteria suchthat a bid rule triggers when the voucher may be redeemed at RestaurantA or a coupon applies to a product made by Brand X. In some embodiments,the rule definition criteria may include other attributes independent ofprice, taxonomy or brand, such as location (e.g., city and zip code),timing (e.g., expiration), or any other voucher-related attributes.

In one embodiment, bid rules submitted by the GVR may be assignedrespective priorities. These priorities may be used in a similar manneras discussed above in order to determine an applicable bid rule ofmultiple bid rules each having bid criteria that match a particularoffer.

Based on the bid rules defined by a particular GVR, the bidding platformmay assign advertising rates to respective voucher/coupon offers of theGVR. For example, when a GVR provides a new voucher offer to the biddingplatform, the bidding platform may analyze attributes of the offer,categorize the offer, and scan the bid rules to determine which of theGVR's bid rules match the attributes and/or categories. The matching bidrule (or the highest priority matching bid rule in the case where thereare multiple matching bid rules) may then be used to set an advertisingrate for the new voucher offer.

Depending on the embodiment, the bid amount may be absolute such thatthe bid amount is used in place of a base CPC rate defined in the ratecard, or the bid amount may be relative such that the bid amount is usedto modify the base CPC rate defined in the rate card by the bid amount.

All of the methods and tasks described herein may be performed and fullyautomated by a computer system. The computer system may in some casesinclude multiple distinct computers or computing devices (e.g., physicalservers, workstations, storage arrays, etc.) that communicate andinteroperate over a network to perform the described functions. Eachsuch computing devices typically includes a processor (or multipleprocessors) that executes program instructions or modules stored in amemory or other non-transitory computer-readable storage medium. Thevarious functions disclosed herein may be embodied in such programinstructions, although some or all of the disclosed functions mayalternatively be implemented in application-specific circuitry (e.g.,ASICs or FPGAs) of the computer system. Where the computer systemincludes multiple computing devices, these devices may, but need not, beco-located. The results of the disclosed methods and tasks may bepersistently stored by transforming physical storage devices such assolid state memory chips and/or magnetic disks, into a different state.

The foregoing description details certain embodiments of the invention.It will be appreciated, however, that no matter how detailed theforegoing appears in text, the invention can be practiced in many ways.It should be noted that the use of particular terminology whendescribing certain features or aspects of the invention should not betaken to imply that the terminology is being re-defined herein to berestricted to including any specific characteristics of the features oraspects of the invention with which that terminology is associated. Thescope of the invention should therefore be construed in accordance withthe appended claims and any equivalents thereof.

What is claimed is:
 1. A method comprising: generating, by a biddingplatform computing device, a computer interface usable by a merchant inorder to place bids for placement of ads for a plurality of productsbased on one or more bid rules, wherein each bid rule comprises: a bidamount indicating an absolute advertising rate or a relative bidadjustment to be made to a base advertising rate; a rule definitioncomprising criteria for identifying products of the merchant associatedwith the respective bid rule, the criteria comprising one or more pricecriteria, taxonomy criteria, or product manufacturer criteria; and abidding priority indicating a respective priority of the bid rule inrelation to other bid rules; transmitting the computer interface to acomputing device of the merchant, and receiving one or more bid rules ofthe merchant from the merchant computing device.